REMARKS 

Claims 1-12, 18-23, 25-26, and 30-31 are pending after this amendment. 

Applicants have amended claims 1, 5, 7, and 18 in order to more particularly 
define the invention. The amendments were not necessitated by the claim rejections. 
Applicants make no admission as to the patentability or unpatentability of the origi- 
nally filed claims. 

Claims 13-17, 24, and 27-29 have been canceled. 

The amendments and remarks presented herein are in response to the Office 
Action dated December 2, 2008. 

On January 22, 2009, the Examiner, the Examiner's supervisor, and Appli- 
cants' representative conducted a telephone interview to discuss the pending Office 
Action. Applicants thank the Examiner and the Examiner's supervisor for the oppor- 
tunity to discuss the rejections and to clarify the issues set forth therein. 

The Examiner rejected claims 14-17 under 35 USC 102(e) as allegedly being an- 
ticipated by Burema. Claims 14-17 have been canceled. 

The Examiner rejected claims 1-12, 18-23, 25-27, and 29-31 under 35 USC 103 
as allegedly being unpatentable over Burema in view of Shrader. This rejection is re- 
spectfully traversed. 
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Claim 1, which has been amended merely to more particularly recite Appli- 
cants' invention, recites: 



"A method for determining whether a client accepts visitor identifiers, comprising the 

steps of: 

a. ) receiving a request for a resource, the request originating at a client; 

b. ) determining whether the request for the resource includes a visitor identi- 

fier; 

c. ) responsive to the request including a visitor identifier: 

obtaining data associated with the visitor identifier; 
determining that the client accepts visitor identifiers; and 
transmitting the requested resource to the client; 

d. ) responsive to the request not including a visitor identifier and responsive 

to the request not including an indicator that redirection has oc- 
curred: 

assigning a new visitor identifier; 

sending a redirection request with the new visitor identifier to the cli- 
ent, the redirection request including an indicator that redi- 
rection has occurred; 

responsive to the client storing the new visitor identifier, determining 
that the client accepts visitor identifiers; 

responsive to the client not storing the new visitor identifier, deter- 
mining that the client does not accept visitor identifiers; and 

transmitting the requested resource to the client." 



The claimed method determines whether a client accepts visitor identifiers. A 
request for a resource is received, for example at a server. The request originates at a 
client. A determination is made as to whether the request includes a visitor identi- 
fier. An example of such a visitor identifier is a cookie, although other types of visi- 
tor identifiers can be used. If the request includes a visitor identifier, data associated 
with the visitor identifier is obtained, a determination is made that the client accepts 
visitor identifiers, and the request is serviced by transmitting the requested resource 
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If the request does not include a visitor identifier, and if the request does not 
include an indicator that redirection has already occurred, a new visitor identifier is 
assigned and a redirection request is sent to the client along with the new visitor 
identifier. The indicator, if present, ensures that the method does not send a redirec- 
tion request if redirection has already occurred; in this manner, the claimed method 
avoids an endless loop. 

If the client stores the new visitor identifier, a determination is made that the 
client accepts visitor identifiers. If the client does not store the new visitor identifier, 
a determination is made that the client does not accept visitor identifiers. The re- 
quest is serviced by transmitting the requested resource to the client. 

Claim 1 thus recites a method wherein, if a visitor identifier is found in the re- 
quest for the resource, the request can be processed without any further communica- 
tions from the client. Specifically, if the request includes a visitor identifier, data is 
obtained, a determination is made that the client accepts visitor identifiers, and the 
requested resource is transmitted to the client. The method also includes an efficient 
mechanism for sending a redirection request in order to determine whether the client 
accepts visitor identifiers when the initial request does not include a visitor identifier. 
An indicator that redirection has occurred is included in the redirection request, so as 
to avoid repeated (and potentially endless) generation of new redirection requests 
when the client fails to return the visitor identifier in the next request. 
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Claim 3 recites: 



"A method for determining whether a requestor accepts visitor identifiers, comprising the 

steps of: 

a. ) receiving a request for a resource from a requestor, the requestor having an ad- 

dress; 

b. ) determining whether the request includes a visitor identifier; 

c. ) responsive to the request including a visitor identifier: 

c.l) obtaining data associated with the visitor identifier; 

c.2) determining that the requestor accepts visitor identifiers; and 

c. 3) transmitting the requested resource to the requestor; and 

d. ) responsive to the request not including a visitor identifier: 

d. l) determining whether the request includes an indicator that step d.3) has 

been performed; 

d.2) responsive to the request including the indicator that step d.3) has been 
performed: 

assigning a visitor identifier from the requestor's address; 
determining that the requestor does not accept visitor identifiers; and 
transmitting the requested resource to the requestor; and 
d.3) responsive to the request not including the indicator that step d.3) has 
been performed: 

assigning a new visitor identifier; 

sending to the requestor a redirection request including the new visi- 
tor identifier and an indicator that step d.3) has been per- 
formed, the redirection request being adapted to cause the 
requestor to retransmit the request for the resource; and 

repeating steps a-d." 



Claim 3 recites a method wherein, if a visitor identifier is found in the request 
for the resource, the request can be processed without any further communications 
from the client. If the request does not include a visitor identifier, a determination is 
made as to whether the request includes an indicator that step d.3 has been per- 
formed, wherein step d.3 includes the assignment of a new visitor identifier and 
transmission of a redirection request. If the request includes an indicator that step 
d.3 has been performed, a determination is made that the requestor does not accept 
visitor identifiers; accordingly a visitor identifier is assigned from the requestor's ad- 
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dress. If the request does not include an indicator that step d.3), then a new visitor 
identifier is assigned, and a redirection request is sent, including an indicator that 
step d.3 has been performed. Steps a-d are then repeated. 

Thus, both claims 1 and 3 specifically recite mechanisms by which an indicator 
is provided; the indicator specifies whether a redirection request has already been 
issued . In this manner, the claimed invention avoids transmitting repeated redirec- 
tion requests that might constitute an endless loop. This endless-loop avoidance 
mechanism is a unique limitation that is not found in either of the cited references. 

Burema merely teaches a tracking system server that writes a test cookie to a 
client to determine whether cookie writing has been disabled at the client. See, for 
example, paragraph [0031]. Also see paragraph [0071]: "The transaction transmittal 
program determines whether a user has disabled the cookie feature on his or her 
computer as follows. . . Each user having cookies enabled will have a test cookie, 
which was written out to the user's computer from the transaction page." 

Burema fails to provide any teaching of a method wherein a redirection re- 
quest is sent to the requestor, including an indicator that the step of sending a redi- 
rection request has been performed. As discussed in a previous Response, Burema 
does not need such a redirection request or indicator because there is no need to de- 
termine whether the request is being received for the first or second time. Therefore, 
Burema actually teaches away from the limitations of the claimed invention. 
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Furthermore, as stated previously, the portions of Burema cited by the Exam- 
iner (paragraphs [0031] and [0071-0078] and Figs. 3a-3b) fail to teach redirection in 
the manner claimed herein. Contrary to the Examiner's assertions, these portions of 
Burema do not teach any mechanism for sending to the requestor a redirection re- 
quest including the new visitor identifier and an indicator that redirection has been 
performed. Burema' s mention of "redirection" merely refers to a referral from an af- 
filiate site to a merchant site , and is completely unrelated to the notion of sending a 
redirection request to cause a requestor to resubmit its resource request, as recited 
herein. The redirection request of the claimed invention is "adapted to cause the re- 
questor to retransmit the request for the resource". By contrast, Burema' s redirection 
is to a merchant site, rather than a retransmission of the resource request. 

For example, paragraph [0072] of Burema states, "If the transaction file does 
not include tracking system information, then transaction information is matched to 
information recorded during the redirection to the merchant's web site." The specific 
description as to what is meant by the term "redirection" is found at paragraph 
[0011]: "The method redirects a client to a merchant site based on a selection made at 
an affiliate site by the client, stores information about the redirection in a database, 
captures, using a script executed by the client browser, transaction information re- 
garding the transaction, receives the transaction information indicating that the client 
completed a transaction at the merchant site and compares the information stored in 
the browser of the client with the transaction information to determine whether the 
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affiliate referred the client to the merchant site." It is apparent from Burema's use of 
the term that there is no hint or suggestion of any technique for sending a redirection 
request to a requestor that causes a request to be retransmitted with a new visitor 
identifier and with an indicator that the redirection step has been performed, as 
claimed herein. 

Shrader does nothing to cure this deficiency of Burema. Shrader merely 
teaches a method for enabling a user to interact with an application running on a 
server by constructing and returning a cookie to the browser upon a given occur- 
rence. As part of a login process, the browser checks with the server that the cookie 
was set by the browser. Shrader describes a specific technique of sending the cookie 
from the server in a refresh page that redirects the HTTP flow back to itself with a 
parameter to check if the cookie was set; the server then performs a test to determine 
whether the cookie is valid (Abstract; also col. 2, lines 34-41; also col. 6, lines 5-26). 

Nowhere in Shrader is there any mention of including an indicator that the 
step of sending a redirection request has been performed, as claimed herein. 
Shrader' s mechanism merely provides a refresh page that redirects HTTP flow back 
itself; no mention is made of any flag or indicator that redirection has been per- 
formed, as claimed herein. 

In the interview of January 22, 2009, the Examiner acknowledged Applicants' 
argument that the indicator that redirection has occurred (which is referred to herein 
as a "do not repeat" indicator, for ease of nomenclature but without any intention to 
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limit the scope of the claimed invention) is absent from the cited references. How- 
ever, the Examiner asserted that the specification fails to provide sufficient descrip- 
tion to enable the claimed limitation with respect to the "do not repeat" indicator. 

On the contrary, the specification provides ample support of the "do not re- 
peat" indicator. Specifically, paragraph [0014] states: 

" [0014] The redirection request also includes a "do not repeat" indicator along 
with the new visitor identifier. The "do not repeat" indicator allows the data collec- 
tion server to recognize this refusal and avoid an endless loop . When the indicator is 
detected, the data collection server does not continue to try to send a new visitor iden- 
tifier to the client, but instead creates a unique visitor identifier based on the client's 
address and a user-agent string. This visitor identifier is not sent to the client, but is 
used by the data collection server to identify the visitor when logging data related to 
the request. In this manner, collection of the visitor identifier and associated data con- 
tinues, without disturbing the client." (Emphasis added). 



Paragraphs [0044] to [0045] state: 

" [0044} However, if the visitor identifier is missing or invalid, the cookie 
handshake process 270 continues by determining whether a "do not repeat" indicator 
is present 230 . If the "do not repeat" indicator is not present, then the cookie handler 
130 assigns a visitor identifier, sets the "do not repeat" indicator, and sends the visitor 
identifier, "do not repeat" indicator and a redirection request 240 to the client 150 via 
the interface 110. The redirection request indicates to the client that the embedded 
content the client is requesting can be found at a particular location. The location 
specified by the cookie handler 130 is the data collection server 100 itself. This redi- 
rection request causes the client 150 to repeat the request to the data collection server, 
but this time including the visitor identifier. 

[0045] However, not all redirection requests will contain the visitor identifier 
assigned by the cookie handler. Some clients, for example, will not accept visitor 
identifiers and therefore will not send the visitor identifier assigned by the cookie 
handler. In other cases, the visitor identifiers may become corrupted or lost during 
transmission due to a poor connection. In these cases, in order to avoid an infinite 
loop in which visitor identifiers are repeatedly created and sent back to the client, the 
cookie handler 130 checks for the "do not repeat indicator" 230 . If the "do not repeat" 
indicator is present, but the request does not include a visitor identifier, the cookie 
handler 130 recognizes that the either the client does not accept visitor identifiers, or 
the visitor identifier has become corrupt or lost. The cookie handler creates a visitor 
identifier based on the client's address 250, and collects the visitor identifier, time 
stamp, page identifier, and other data associated with the request 260. The client's 
address may include the client's address alone, or it may include the client's address 
in combination with a user-agent string or any other identifying data. These items 
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may then be stored in the repository as a normal click-stream entry occurring with a 
visitor identifier created by the cookie handshake process 270." (Emphasis added). 

Additional support appears in Fig. 2, which specifically teaches the sending of 
a "do not repeat" indicator at step 240, as well as the checking for such an indicator 
at step 230. 

These teachings in the present specification clearly set forth sufficient support 
for the limitations recited in the claims, and indeed provide additional descriptions 
as to the operation and purpose of the "do not repeat" indicator. 

One skilled in the art will recognize that many different well-known mecha- 
nisms can be used for encoding an indicator, flag, parameter, or other value in a re- 
quest such as an HTTP request. In particular, it is well known to encode flags and 
indicators in URL request strings, which can be parsed at a server in order to extract 
query parameters, state information, data entered in form fields, and/ or client- 
identifying information. 

For example, it is well known to encode data in a query string portion of a 
URL, in order to pass data to a web application. See, for example, Berners-Lee, et al, 
RFC 1738, Uniform Resource Locators (URL), December 1994, available at 
http://tools.ietf.org/html/rfcl738, and Berners-Lee, et al; and RFC 2396, URI Ge- 
neric Syntax, August 1998, available at http://tools.ietf.org/html/rfc3986 (later su- 
perseded by RFC 3986). Even in the earliest days of the World Wide Web, URL re- 
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quest strings were known to have a query string portion, by which information could 
be passed from a client to a server as part of an HTTP request. 

Such techniques for encoding information in URL request strings are well 
known, so that one skilled in the art would recognize these techniques as being well- 
adapted to use herein to carry the "do not repeat" indicator. One skilled in the art 
reading Applicants' disclosure would recognize the need to include in a redirection 
request an indicator that redirection has occurred. The individual skilled in the art 
would recognize, upon reading the disclosure, that one possible mechanism would 
be to encode such an indicator in the transmitted URL redirection request, according 
to the above-cited RFC documents. Given the specification's explicit recitation of in- 
cluding a "do not repeat" indicator in a redirection request, the individual skilled in 
the art would not need any additional recitation to recognize that URL encoding (or 
any other equivalent method) could be used as a mechanism for including the indica- 
tor in the request. "Detailed procedures for making and using the invention may not 
be necessary if the description of the invention itself is sufficient to permit those 
skilled in the art to make and use the invention." MPEP 2164. 

Applicants emphasize that they are not asserting that the above-cited RFC 
documents contain any teaching of the use of a "do not repeat" indicator encoded in 
a URL string. Rather, Applicants merely point out that the general mechanism for 
encoding data in a URL string was well known at the time the present application 
was filed. Accordingly, once given the information provided in Applicants' disclo- 
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sure, one skilled in the art would recognize the need to include an indicator that redi- 
rection has occurred, and would therefore turn to existing techniques for encoding 
data in a request (such as URL encoding) to implement Applicants' claimed inven- 
tion. 

Accordingly, even in the absence of an explicit teaching of URL encoding in 
the specification, Applicants respectfully submit that adequate support for the 
claimed invention is set forth therein, and that the invention is described in sufficient 
detail to enable one skilled in the art to make and use the claimed invention. 

It is acknowledged, however, that other techniques for transmitting flags and 
indicators may exist or may be developed in the future, and that the method claimed 
herein is not limited to any particular mechanism for transmitting the indicator that 
redirection has occurred. 

Accordingly, claim 1 is respectfully submitted to be patentable over Burema 
and Shrader, taken alone or in any combination. 

Claim 11 recites a data collection server and includes limitations similar to 
those discussed in connection with claim 3. Claim 18 recites a computer program 
product including limitations similar to those discussed in connection with claim 1. 
Claim 19 recites a computer program product including limitations similar to those 
discussed in connection with claim 3. Claims 2, 4-10, 12, 20-23, 25-26, and 30-31 vari- 
ously depend from claims 1, 3, 11, and 19 and incorporate the limitations discussed 
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above. Accordingly, claims 1-12, 18-23, 25-26, and 30-31 are hereby submitted to be 
patentable over Burema and Shrader, taken alone or in any combination. 
Claims 13-17, 24, and 27-29 have been canceled. 



Support for the claim amendments can be found in the originally filed specifi- 
cation at, for example, paragraphs [0042] to [0046] and Fig. 2. No new matter has 
been added. 



On the basis of the above amendments, consideration of this application and 
the early allowance of all claims herein are requested. 

Should the Examiner wish to discuss the above amendments and remarks, or 
if the Examiner believes that for any reason direct contact with Applicants' represen- 
tative would help to advance the prosecution of this case to finality, the Examiner is 
invited to telephone the undersigned at the number given below. 

Respectfully submitted, 
Brett Error, et al. 



Dated: March 31, 2009 By: / Amir H. Raubvogel/ 

Amir H. Raubvogel 
Reg. No. 37,070 
Raubvogel Law Office 
820 Lakeview Way 
Redwood City, CA 94062 
Phone: (650) 209-4884 
Fax: (650) 362-1800 
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